Today, computing devices are almost always interconnected via networks. These networks can be large closed networks, as within a corporation, or truly public networks, as with the Internet. A network itself might have hundreds, thousands or even millions of potential users. Consequently it is often required to restrict access to any given networked computer or service, or a part of a networked computer or service, to a subset of the users on the public or closed network. For instance, a brokerage might have a public website accessible to all, but would like to only give Ms. Alice Smith access to Ms. Alice Smith's brokerage account.
Access control is an old problem, tracing its roots to the earliest days of computers. Passwords were among the first techniques used, and to this day remain the most widely used, for protecting resources on a computer or service.
Single-Factor Authentication
In its simplest form, known as single factor authentication, every user has a unique password and the computer has knowledge of the user password. When attempting to log on, Alice would enter her userid, say alice, and password, say apple23, the computer would compare the pair, i.e. alice, apple23, with the pair it had stored for Alice, and if there is a match would establish a session and give Alice access.
This simple scheme suffers from two problems. First, the table containing the passwords is stored on the computer, and thus represents a single point of compromise. If Eve could somehow steal this table, she would be able to access every user's account. A second problem with this approach is that when Alice enters her password it travels from her terminal to the computer in the clear, and Eve could potentially eavesdrop. Such eavesdropping is known as a Man-In-The-Middle attack. For instance the terminal could be Alice's PC at home, and the computer could be a server on the Internet, in which case her password travels in the clear on the Internet. It will be recognized by those with ordinary skill in the art that a Man-in-The-Middle attack can go beyond eavesdropping, to modifying the contents of the communication.
Various solutions have been proposed and implemented to address these two issues. For instance, to address the first problem of storing the password on the computer, the computer could instead store a one way function of the password, e.g. F(apple23)=XD45DTY, and the pair {alice, XD45DTY}. In this example as F(apple23) is a one way function, computing XD45DTY from apple23 is easy, but as it is a “one way function”, the reverse is believed to be computationally difficult or close to impossible. So when Alice logs on and sends the computer {alice, apple23}, the computer can compute F(apple23) and compare the result with XD45DTY. The UNIX operating system was among the first to implement such a system in the 1970's. However, this approach, while addressing the problems due to the storage of the password on the computer, does not address the problem of the password traveling in the clear.
Multifactor Authentication
Multiple factor authentication also exists as a potential solution to the problems inherent with single factor authentication. In multiple factor authentication, at least knowledge of, if not actual possession of, two or more factors must be shown for authentication to be complete. It should be understood that in multiple factor authentication, each factor remains separate. That is, the factors are not combined. Further, the factors are not even concatenated. Several multiple factor authentication techniques exist, including one time password token techniques, encrypted storage techniques, smart card techniques, and split key techniques.
In one time password token techniques, two passwords are utilized, one being a permanent password associated with the user, and the other being a temporary, one-time use, password generated by a password generator. The permanent password may be optional. The temporary password has a finite usable life, such as sixty seconds. At the end of the useable life, another temporary password is generated. An authentication server knows each usable password as well as its useable life, based upon algorithms well known to those of ordinary skill in the art. A user transmits both the permanent password (first factor) and a temporary password (second factor) to the authentication server which then verifies both passwords. The passwords are transmitted in the clear, thus token techniques are subject to man-in-the-middle attacks.
Storage of Crypto-Keys
Using encrypted storage techniques, a cryptographic key is stored on either removable media or a hard drive. The cryptographic key is encrypted with a user's password. After decryption with the user's password, the key is then stored, at least temporarily, in memory of the user's computer system where it is used to either encrypt or decrypt information. As will be recognized by those of ordinary skill in the art, this particular approach is undesirable due to it being susceptible to a dictionary attack, to be discussed in detail further below.
In smart card techniques, a private portion of an asymmetric cryptographic key is stored on a smart card, which is portable. A specialized reader attached to a computer system is used to access the smart card. More particularly, the user enters a PIN (the first factor) to ‘unlock’ the smart card. Once unlocked, the smart card encrypts or decrypts information using the key stored thereon. It should be stressed that in smart card techniques the key never leaves the smart card, unlike in the encrypted storage techniques discussed above. Rather, electronics within the smart card itself perform the encrypting and/or decrypting. Smart card techniques are associated with certain problems. These problems include the fact that the technique is costly to implement, due to hardware costs. Further, a lack of readers makes use of a user's smart card difficult, and smart cards themselves are subject to loss.
Symmetric and Asymmetric Cryptography
Before discussing in detail the more sophisticated conventional techniques for authentication, which are based upon split key technology, let us briefly describe symmetric and asymmetric key cryptography.
In symmetric key cryptography, the two parties who want to communicate in private share a common secret key, say K. The sender encrypts a message with K, to generate a cipher, i.e. C=Encrypt(M,K). The receiver decrypts the cipher to retrieve the message, i.e. M=Decrypt(C,K). An attacker who does not know K, and sees C, cannot successfully decrypt the message M, if the underlying algorithms are strong. Examples of such systems are DES3 and RC4. Encryption and decryption with symmetric keys provide a confidentiality, or privacy service.
Symmetric keys can also be used to provide integrity and authentication of messages in a network. Integrity and authentication means that the receiver knows who sent a message and that the message has not been modified so it is received as it was sent. Integrity and authentication is achieved by attaching a Message Authentication Code (MAC) to a message M. E.g., the sender computes S=MAC(M,K) and attaches S to the message M. When the message M reaches the destination, the receiver also computes S′=MAC(M,K) and compares S′ with the transmitted value S. If S′=S the verification is successful, otherwise verification fails and the message should be rejected. Early MACs were based on symmetric encryption algorithms such as DES, whereas more recently MACs are constructed from message digest functions, or “hash” functions, such as MD5 and SHA-1. The current Internet standard for this purpose is known as hash-based MAC (HMAC).
By combining confidentiality with integrity and authentication, it is possible to achieve both services with symmetric key cryptography. It is generally accepted that different keys should be used for these two services and different keys should be used in different directions between the same two entities for the same service. Thus if Alice encrypts messages to Bob with a shared key K, Bob should use a different shared key K′ to encrypt messages from Bob to Alice. Likewise Alice should use yet another key K″ for MACs from Alice to Bob and Bob should use K′″ for MACs from Bob to Alice. Since this is well understood by those skilled in the art, we will follow the usual custom of talking about a single shared symmetric key between Alice and Bob, with the understanding that strong security requires the use of four different keys.
Symmetric key systems have always suffered from a major problem—namely how to perform key distribution. How do Bob and Alice agree on K?
Asymmetric key cryptography was developed to solve this problem. Here every user is associated with a private/public key pair, commonly referred to as D and E, which are related by special mathematical properties. These properties result in the following functionality: a message encrypted with one of the two keys can then only be decrypted with the other.
One of these keys for each user is made public and the other is kept private. Let us denote the former by E, and the latter by D. So Alice knows Dalice, and everyone knows Ealice. To send Alice the symmetric key K, Bob simply sends ciphertext C=Encrypt(K,Ealice). Alice, and only Alice (since no one else knows Dalice), can decrypt the ciphertext C to recover the message, i.e. Decrypt(C,Dalice)=K. Now both Alice and Bob know K and can use it for encrypting subsequent messages using a symmetric key system. Why not simply encrypt the message itself with the asymmetric system? This is simply because in practice all known asymmetric systems are fairly inefficient, and while they are perfectly useful for encrypting short strings such as K, they are inefficient for large messages.
The above illustrates how asymmetric cryptography can solve the key distribution problem. Asymmetric cryptography can also be used to solve another important problem, that of digital signatures. To sign a message M, Alice encrypts it with her own private key to create S=Encrypt(M,Dalice). She can then send (M,S) to the recipient who can then decrypt S with Alice's public key to generate M′, i.e. M′=Decrypt(S,Ealice). If M′=M then the recipient has a valid signature as only someone who has Dalice, by definition only Alice, can generate S, which can be decrypted with Ealice to produce M. To convey the meaning of these cryptographic operations more clearly they are often written as S=Sign(M,Dalice) and M′=Verify(S,Ealice). It is worth noting that asymmetric key digital signatures provide non-repudiation in addition to the integrity and authentication achieved by symmetric key MACs. With MACs the verifier can compute the MAC for any message M of his choice, since the computation is based on a shared secret key. With digital signatures this is not possible since only the sender has knowledge of the sender's private key required to compute the signature. The verifier can only verify the signature, but not generate it. It will be recognized by those skilled in this art that there are numerous variations and elaborations of these basic cryptographic operations of symmetric key encryption, symmetric key MAC, asymmetric key encryption and asymmetric key signatures.
The RSA cryptosystem is one system that implements asymmetric cryptography as described above. In particular the RSA cryptosystem allows the same private-public key pair to be used for encryption and for digital signatures. It should be noted that there are other asymmetric cryptosystems that implement encryption only e.g., EIGamal, or digital signature only, e.g., DSA. Technically the public key in RSA is a pair of numbers E, N and the private key is the pair of numbers D, N. When N is not relevant to the discussion, it is commonplace to refer to the public key as E and the private key as D.
Finally, the above description does not answer the important question of how Bob gets Alice's public key Ealice. The process for getting and storing the binding [Alice, Ealice] which binds Ealice to Alice is tricky. The most practical method appears to be to have the binding signed by a common trusted authority. So such a “certificate authority” (CA) can create CERTalice=Sign([Alice, Ealice], Dca). Now CERTalice can be verified by anyone who knows the CA's public key Eca. So in essence, instead of everyone having to know everyone else's public key, everyone only need know a single public key, that of the CA. More elaborate schemes with multiple Certificate Authorities, sometimes having a hierarchical relationship, have also been proposed.
Asymmetric key cryptosystems have been around for a long time, but have found limited use. The primary reasons are twofold: (a) the private key D in most systems is long, which means that users cannot remember them, and they have to either be stored on every computer they use, or carried around on smart cards or other media; and (b) the infrastructure for ensuring a certificate is valid, which is critical, is cumbersome to build, operate, and use. The first technique proposed to validate certificates was to send every recipient a list of all certificates that had been revoked. This clearly does not scale well to an environment with millions of users. A later technique proposed to validate certificates was to require that one inquire about the validity of a certificate on-line, which has its own associated problems.
Split Private Key Asymmetric Cryptography
A system based on split private key asymmetric cryptography has been developed to solve these two issues, i.e. long private keys and certificate validity, among others. In this system the private key for Alice, i.e. Dalice, is further split into two parts, a part Daa which Alice knows, and a part Das which is stored at a security server, where Daa*Das=Dalice mod Φ(N). To sign a message, Alice could perform a partial encryption to generate a partial signature, i.e. PS=Sign(M,Daa). Alice then sends the server PS which ‘completes’ the signature by performing S=Sign(PS,Das). This completed signature S is indistinguishable from one generated by the original private key, i.e. Dalice, so the rest of the process works as previously described. However, Daa can be made short, which allows the user to remember it as a password, so this system is user friendly. Further, if the server is informed that a particular ID has been suspended or revoked, then it will cease to perform its part of the operation for that user, and consequently no further signatures can ever be performed. This provides for instant revocation in a simple, highly effective fashion. It will be recognized by those skilled in the art that a split private key can be used in a similar manner for decryption purposes, and that the partial signatures (or encryptions) may be performed in the reverse sequence, that is first by the security server and subsequently by the user's computer, or may even be performed concurrently in both places and then combined.
Password Based Cryptography
Let us return now to password based systems. Challenge-response systems solve the issue of having to send passwords in the clear across a network. If the computer and Alice share a secret password, P, then the computer can send her a new random challenge, R, at the time of login. Alice computes C=Encrypt(R,P) and sends back C. The computer decrypts Decrypt(C,P)=C′. If C=C′, then the computer can trust that it is Alice at the other end. Note however that the computer had to store P.
A more elegant solution can be created using asymmetric cryptography. Now Alice has a private key Dalice, or in a split private key system she has Daa. The computer challenges her to sign a new random challenge R. She signs the challenge, or in the split private key system she interacts with the security server to create the signature, and sends it back to the computer which uses her public key, retrieved from a certificate, to verify the signature. Observe that the computer does not have to know her private key, and that an eavesdropper observing the signature on R gains no knowledge of her private key.
The SSL system, which is widely used on the Internet, in effect implements a more elaborate method of exactly this protocol. SSL has two components, ‘server side SSL’ in which a server proves its identity by correctly decrypting a particular message during connection set-up. As browsers such as Netscape and Microsoft Internet Explorer come loaded with the public keys of various CAs, the browser can verify the certificate of the server and use the public key therein for encryption This authenticates the server to the client, and also allows for the set-up of a session key K, which is used to encrypt and MAC all further communications. Server side SSL is widely used, as the complexity of managing certificates rests with system administrators of web sites who have the technical knowledge to perform this function. The converse function in SSL, client side SSL, which lets a client authenticate herself to a server by means of a digital signature is rarely used, because although the technical mechanism is much the same, it now requires users to manage certificates and long private keys which has proven to be difficult, unless they use the split private key system. So in practice, most Internet web sites use server side SSL to authenticate themselves to the client, and to obtain a secure channel, and from then on use Userid, Password pairs to authenticate the client.
So far from disappearing, the use of passwords has increased dramatically. Passwords themselves are often dubbed as inherently “weak”. This is inaccurate because, if they are used carefully, passwords can actually achieve “strong” security. As discussed above, passwords should not be sent over networks, and if possible should not be stored on the receiving computer. Instead, in a “strong” system, the user can be asked to prove knowledge of the password without actually revealing the password. Perhaps most critical is that passwords should not be vulnerable to dictionary attacks.
Dictionary Attacks
Dictionary attacks can be classified into three types. In all three types the starting point is a ‘dictionary’ of likely passwords. Unless the system incorporates checks to prevent it, users tend to pick poor passwords, and compilations of lists of commonly used poor passwords are widely available.
On line dictionary attack: Here the attacker types in a guess at the password from the dictionary. If the attacker is granted access to the computer they know the guess was correct. These attacks are normally prevented by locking the user account if there are an excessive number of wrong tries to gain access. Note that this very commonly used defense prevented one problem, but just created another one. An attacker can systematically go through and lock out the accounts of hundreds or thousands of users. Although the attacker did not gain access, now legitimate users cannot access their own accounts either, creating a denial of service problem.
Encrypt dictionary attacks: If somewhere in the operation of the system a ciphertext C=Encrypt(M,P) was created, and the attacker has access to both C and M, then the attacker can compute off-line C1=Encrypt(M,G1), C2=Encrypt(M,G2), . . . where G1, G2, . . . etc. are the guesses at the password P from the dictionary. The attacker stops when he finds a Cn=C, and knows that Gn=P. Observe that the UNIX file system, which uses a one way function F( ) instead of an encryption function E( ), is vulnerable to this attack.
Decrypt dictionary attacks: Here the attacker, does not know M, and only sees the ciphertext C (where C=Encrypt(M,P)). The system is only vulnerable to this attack if it is true that M has some predictable structure. So the attacker tries M1=Decrypt(C,G1), M2=Decrypt(C,G2) . . . , and stops when the Mi has the structure he is looking for. For instance Mi could be known to be a timestamp, English text, or a number with special properties such as a prime, or a composite number with no small factors. Those with ordinary skill in the art will recognize there are numerous variations of the encrypt and decrypt dictionary attacks.
In split private key systems, the user portion of the private key, referred to as Daa above, may come from the user's password only. Thus, a compromise of the password, i.e, another person learning a user's password, results in a compromise of the split private key system. Also, there still remains the possibility of a dictionary attack on the server portion of the private key, referred to as Das above, because the user portion of the private key comes from the user's password only. Thus knowledge of Das enables a dictionary attack on Daa. As discussed above, many of the existing multiple factor systems that address these problems rely upon expensive hardware. Because of this and other reasons, such systems have failed to gain widespread support. However, as will be discussed further below, recently a multifactor cryptographic system was developed which overcomes these problems.
Multifactor Split Private Key Asymmetric Cryptography
In particular, as disclosed in U.S. application Ser. No. 11/055,987, filed Feb. 14, 2005, and entitled “Architecture For Asymmetric Crypto-key Storage”, to overcome these problems Tricipher, Inc, the assignee of all rights in the present application, has developed an asymmetric cryptosystem in which users are associated with an asymmetric crypto-key having a public key and a private key split into multiple private key portions. As in the conventional split key asymmetric cryptosystems discussed above, each of the private key portions can be applied to an original message separately or in sequence and the partial results combined to form a transformed, i.e. encrypted, message, and the public key can be applied to the transformed message to verify authenticity of the message preferably by recovering the original message, which authenticates the user. Conversely a message transformed, i.e. encrypted, with the public key can be decrypted by applying each of the private key portions to the transformed message separately or in sequence and the partial results combined to decrypt the original message.
However, unlike the conventional split key asymmetric cryptosystem discussed above, the Tricipher system generates at least one of the multiple private key portions of the asymmetric crypto-key using multiple pieces of information, known as factors. For purposes of the following discussion, we will assume that a first private key portion of the asymmetric crypto-key is generated using multiple factors. The multiple factors could be two factors, three factors, or any number of multiple factors, as may be desired under the circumstances. In any event, each of the multiple factors is under the control of a single entity. That is, the single entity has possession of, or free access to, each of the multiple factors. For purposes of the following discussion, we will assume that the entity associated with the first private key portion is a user. Thus, the first private key portion could be Daa.
A factor could be as simple as a readily available number string, such as a serial number of a user's computer, or could be a sophisticated algorithm, such as a cryptographic key. Preferably, one of the factors corresponds to the user's password. If each of the multiple factors is a number string, generation of the first private key portion could be accomplished by simply concatenating the multiple factors. However, advantageously, the first private key portion is generated by cryptographically combining the multiple factors, and each of the multiple factors is, or is used to produce, a cryptographic key. Thus, cryptographic keys are beneficially used to produce a cryptographic key.
The first private key portion is not stored in a persistent state. That is, the first private key portion must be generated whenever its use is desired. The first private key portion may be immediately destroyed after its initial use, or may be stored temporarily after its generation, making it available for use multiple times before it is destroyed, for example for use during a predetermined time period or for use a predetermined number of times.
Another of the multiple private key portions of the asymmetric crypto-key, which will be referred to as the second private key portion for purposes of this discussion, is under control of another entity, in this case an entity other than the applicable user, e.g. a secure server or another user. Thus, the second private key portion could be Das. This second private key portion may be stored in a persistent state. In this example, it is assumed that the first and second private key portions of the asymmetric crypto-key are combinable to form a complete private key Dalice. This private key is usable to transform, e.g. encrypt or decrypt, messages as may be desired under the circumstances.
Thus, in the multifactor split private key asymmetric cryptosystem developed by Tricipher, Inc, one of multiple private key portions of an asymmetric crypto-key, e.g. the user's private key portion, is generated using multiple factors, with each of these factors being under the control of the applicable entity, e.g. that user. This results in a private key that provides greater security than the private keys in other split private key asymmetric cryptosystems in which each entity's, e.g. each user's, private key portion is generated using only a single factor.
Additionally, in the multifactor split private key asymmetric cryptosystem developed by Tricipher, Inc, preferably some, but not all, of the multiple factors used to generate the user's private key portion may be stored, with each stored in a in different location. For example, if one of the factors corresponds to the user's password, preferably neither the user's password nor the corresponding factor is stored, except temporarily on random access memory (RAM) for only the time necessary, in the case of the password, to allow for generation of the corresponding factor after the user enters the password and, in the case of the corresponding factor, to allow for generation of the first private key portion after the corresponding factor has been generated. On the other hand, the other of the multiple factors may be stored. Thus, if there are two other factors, these later two factors are preferably stored separately at different locations. This adds a level of security, in that a thief would have to infiltrate two locations to steal both of these factors.
In this regard, one of these later factors may be stored on either a user's computing device or removable media configured to communicate with the user's computing device. As will be recognized by those skilled in the art, the user's computing device could be a personal computer (PC), personal computing device, mobile phone or some other type computing device, and the removable media could be a USB flash drive, smart card, floppy disk, compact disk (CD) or some other type of portable data storage device. A factor stored on a user's computing device is sometime referred to as Dtether and a factor stored on removable media is sometime referred to as DUSB.
The first private key portion is temporarily stored after being generated. During this temporary storage, it is usable to prove the user's identity multiple times without the user providing any authentication information. This temporary storage could be limited to a predefined time period, or a predefined number of authentications.
The public key, commonly designated as E, is preferably stored under control of an entity other than the entity having access to the multiple factors, e.g. other than the applicable user in the above example. Thus, the public key is available to at least one other entity.
In the multifactor split private key asymmetric cryptosystem developed by Tricipher, Inc., another of the private key portions of the split private key may also be generated based on the same or other multiple factors, which could be partially or completely under the control of the same or another entity, e.g. could be under the control of the applicable user or another entity in the example above. In any event, this other private key portion could be generated based on multiple factors in same manner as described above for the first private key portion.
As described in the above referenced application, in the multifactor split private key asymmetric cryptosystem developed by Tricipher, Inc., the factor Dtether is preferably the private key of a private-public asymmetric key pair, including Dtether and Etether, and having a modulus Ntether. The factor DUSB is preferably the private key of a private-public asymmetric key pair, including DUSB and EUSB, and having a modulus NUSB. For example, Dtether and Etether and/or DUSB and EUSB may form a conventional RSA private-public asymmetric key pair.
The non-private parts of the generated keys, i.e., Etether, Ntether, EUSB, and NUSB, are stored, for example, at a trusted server. In the most common implementation, Dtether is stored securely on the hard disk of a user's PC using the protection capabilities provided by the PC's operating system, preferably as a non-exportable private key in a Windows Operating System key-store. Of course, as desired, Dtether could be stored in a Windows Operating System registry. Alternatively, Dtether can be, as desired, stored on the trusted processing module (TPM). No matter where or how on the user's computing device Dtether is stored, in the most basic configuration, Dtether can only be used from the user's computing device upon which it is stored. That is, Dtether is a non-exportable private key stored on the user device upon which it will be used. However, the multifactor split private key asymmetric cryptosystem developed by Tricipher, Inc. also facilitates porting Dtether to other devices for use thereon.
DUSB, which is stored on removable media, also needs to be protected, since storing any kind of key in the clear should be avoided if possible. In the case of DUSB this is particularly important because if DUSB is stored on the removable media in clear and should the user misplace or otherwise lose the removable media, an attacker could easily access, extract and/or copy DUSB from the removable media, and potentially use DUSB to impersonate the user. Thus, in the multifactor split private key asymmetric cryptosystem developed by Tricipher Inc., DUSB is beneficially stored on the removable media in an encrypted state.
Preferably, encryption of DUSB is not performed with the user's password, because this would still leave DUSB vulnerable to dictionary attacks and guessing attacks. If the factors include both Dtether and DUSB, DUSB may, as disclosed in the above referenced application, be encrypted using Dtether, which is stored, for example, on the user's PC.
However, if DUSB is encrypted using Dtether, an attacker with access to the removable media, as well as the user's PC or other computing device storing Dtether and the user's password could obtain Dtether from the user's computing device, decrypt DUSB by applying Dtether, and then use the user's password, DUSB and Dtether to generate the first private key portion, e.g. Daa. Having the first private key portion, the attacker would now be in a position to impersonate the user. Furthermore, in cases where the factors include DUSB, but not Dtether there is no tethering key to encrypt DUSB.
As will be discussed further below, recently a multifactor cryptographic system was developed which overcomes these problems.
Rolling Key Security for Multifactor Split Private Key Asymmetric Cryptograhy
In particular, as disclosed in concurrently filed U.S. application Ser. No. 11/332,204, filed Jan. 17, 2006, and entitled “Multifactor Split Asymmetric Crypto-Key With Rolling Key Security”, Tricipher, Inc., which is also the assignee of all rights in the present application, has developed a technique for enhancing security of a stored factor which will be used to generate a portion of a private key of a split private key asymmetric cryptosystem.
In accordance with the technique described in the above referenced application, a factor, such as the above described DUSB, is first stored, for example on a user's USB flash memory device, after being encrypted with the private rolling key, sometimes referred to as DR, or public rolling key, sometimes referred to as ER, of a generated RSA or other type first asymmetric rolling crypto-key. The one first rolling key, e.g. DR, used for the encryption is also stored with the encrypted factor. The other first rolling key, e.g. ER, which has not been used to encrypt the factor, is stored elsewhere for access by another entity. For example, the other rolling key might be stored on a sponsor's network server.
In one described implementation, when the user desires to login, the encrypted factor, e.g., DUSB, and the one first rolling key, e.g. DR, stored with the encrypted factor are retrieved from storage. Proof of knowledge of the retrieved first rolling key, e.g. DR, and a request for the other first rolling key, e.g. ER, are transmitted via a network, such as the Internet, by the user to the other entity. The other entity can authenticate the user based on the transmitted proof of knowledge of the one first rolling key, e.g. DR, and the other first rolling key, e.g. ER, which had been previously stored for access by the other entity. If the user is authenticated, the other first rolling key, e.g. ER, is transmitted via the network by the other entity to the user in response to the transmitted request. The user can decrypt the retrieved encrypted factor, e.g., DUSB, with the received other first rolling key, e.g. ER, and use the decrypted factor to generate the applicable private key portion of the user's asymmetric crypto-key. The user can then complete the login with the decrypted factor, e.g., DUSB.
After this log in, and in preparation for a later login by the user, the factor is again encrypted, but this time with a different rolling key. That is, the factor, e.g. DUSB, is next stored, for example on a user's USB flash memory device, after being encrypted with a different private rolling key, e.g. DR1, or public rolling key, e.g. ER1, of a generated RSA or other type second asymmetric rolling crypto-key. The second rolling key, e.g. DR1, used for the encryption is stored with the encrypted factor. The other second rolling key, e.g. ER2, which has not been used to encrypt the factor, is stored elsewhere, e.g. at a sponsor's network server, for access by the other entity.
The next time the user desires to login, the encrypted factor, e.g., DUSB, and the second rolling key, e.g. DR1, stored with the encrypted factor are retrieved from storage. The proof of knowledge of the retrieved second rolling key, e.g. DR1, and a request for the other second rolling key, e.g. ER1, are transmitted via a network, such as the Internet, by the user to the other entity. The other entity can authenticate the user based on the transmitted proof of knowledge of the one second rolling key, e.g. DR1, and the other first rolling key, e.g. ER1, which had been previously stored for access by the other entity. If the user is authenticated, the other first rolling key, e.g. ER1, is transmitted via the network by the other entity to the user in response to the transmitted request. The user can decrypt the retrieved encrypted factor, e.g., DUSB, with the received other first rolling key, e.g. ER1, and use the decrypted factor to generate the applicable private key portion of the user's asymmetric crypto-key. The user can then complete the login. The same technique is repeated after each login, so that the stored factor is always secured with a new rolling key after each prior login.
While the rolling key technique described in the above referenced application significantly enhances security of a stored factor needed to created a split private key, or for that matter a stored factor needed to create any crypto-key, it does not enhance security of the applicable private key portion of the user's asymmetric crypto-key after it has been generated.
In this regard, if the applicable generated private key portion, e.g. DU1, of the user's asymmetric crypto-key is allowed to be used only once after it has been generated, and is then be destroyed, it will only be available to an attacker for a very limited period of time. While this would result in the applicable generated private key portion, e.g. DU1, being relatively secure, it would not be very convenient for the user. That is, under such a protocol, the user would be required to regenerate the applicable private key portion, which may require reentry of the user's password, again and again and again. For example, to obtain access to different information at the same Web site during the same session, could require that the user reenter the user's password and regenerate the applicable private key portion, e.g. DU1, from the applicable factor(s) 2, 3, 4, or even more times. Similarly, to obtain access to information at different network sites during the same session, could require that the user reenter the user's password and regenerate the applicable private key portion, e.g. DU1, from the applicable factor(s) to access each different network site.
On the other hand, if the applicable generated private key portion, e.g. DU1, is allowed to be used repeatedly without requiring the user to reenter the user's password or to regenerate the applicable private key portion, e.g. DU1, for each and every successive use, the applicable private key portion, e.g. DU1, will be relatively less secure, since it will be available to an attacker for a longer period of time. The reduced security can potentially be mitigated to some extent by protecting the generated private key portion, e.g. DU1, while it is stored on, for example, RAM, during its period of use. In this regard, the stored private key portion, e.g. DU1, can be encrypted to make it more difficult for an attacker to gain knowledge of the private key portion in a usable form during the period of use.
However, even if the private key portion, e.g. DU1, is encrypted or protected while it is stored during the period of use, there will always be some period(s) during which the private key portion, e.g. DU1, must be available to an attacker in the clear, i.e. in an unprotected state. So there will be a window(s) of opportunity for an attacker to gain access to the applicable private key portion, e.g. DU1. While the length of the window(s) will depend on whether or not protection is used and the type of protection that is employed during the period of use, it will be recognized that there will be some period(s), however small in length, when the applicable private key portion, e.g. DU1, must be available in the clear and a window(s) of vulnerability to an attack will exist.
Accordingly, a need exists for better techniques for securing the private key portion of the user's asymmetric crypto-key if, after successful login, the user is not require to re-authenticate in order to access different network sites or different information at a network site during a session.